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Abstract — Bitcoin is a decentralized P2P digital currency 
in which coins are generated by a distributed set of miners 
and transaction are broadcasted via a peer-to-peer network. 
While Bitcoin provides some level of anonymity (or rather 
pseudonymity) by encouraging the users to have any number 
of random-looking Bitcoin addresses, recent research shows that 
this level of anonymity is rather low. This encourages users to 
connect to the Bitcoin network through anonymizers like Tor and 
motivates development of default Tor functionality for popular 
mobile SPV clients. In this paper we show that combining Tor and 
Bitcoin creates an attack vector for the deterministic and stealthy 
man-in-the-middle attacks. A low-resource attacker can gain full 
control of information flows between all users who chose to use 
Bitcoin over Tor. In particular the attacker can link together 
user's transactions regardless of pseudonyms used, control which 
Bitcoin blocks and transactions are relayed to the user and can 
delay or discard user's transactions and blocks. In collusion with 
a powerful miner double-spending attacks become possible and a 
totally virtual Bitcoin reality can be created for such set of users. 



I. Introduction 

Bitcoin is a decentralized virtual currency and a P2P 
payment system in which coins are generated by miners and 
double spending is prevented by that each peer keeps a local 
copy of the constantly growing public ledger of all the previous 
transactions. Though the original Bitcoin paper states that 
privacy in such a system may still be maintained, the recent 
findings disprove this. Anonymity and privacy of the plain 
Bitcoin protocol is also not claimed by the Bitcoin developers. 

There are two independent problems: a) ability of the 
attacker to link transactions to the IP address of the 
user (TJ, ATI . iflOl by studying connectivity and traffic of 
the peers and b) linkability of the user's pseudonyms and 
transactions in the public ledger achieved via graph and 
transaction flow analysis lfl6l . 1131 . At the same time as 
Bitcoin increases its user base and moves from mining and 
hoarding to the actual use as a currency and payment protocol 
in various on-line applications there is a growing demand in 
more privacy among the Bitcoin users. While one could use a 
Bitcoin mixing servic^jto break connections in the transaction 
graph, IP address leakage is still possible. Bitcoin developers 
recommend to use third party anonymization tools like Tor 
or VPNs to solve this problem. Seeing this shortcomming 
of Bitcoin some alternative currencies like BitTor, Stealthcoin 
and others, offer native support for Tor. There are also several 
other use cases for Tor in the Bitcoin ecosystem. For mobile 
payments it is of interest to use so called SPV (simple payment 
verification) clients which cannot afford to hold the full 20 

1 Some of them unfortunately did not provide much security and require to 
trust the service operator. 



Gbyte blockchain ledger. Such feature was already foreseen 
in the original Bitcoin whitepaper, see Section 8 of |14|. 
Since such popular clients (around 1 Million userbase [9|) are 
vulnerable to spoofing attacks which may result in double- 
spending, the current trend is to bundle them with Tor by 
default to avoid spoofing and man-in-the-middle attacks |4|, 
Q. Tor can also be a solution for services and online shops that 
want to prevent DoS attacks against their public IP. Finaly Tor 
is seen as a countermeasure for the case if Internet neutrality 
towards Bitcoin will start to erode (6). 

Tor is not a panacea however and not all applications 
are anonymized equally well when combined with Tor. The 
biggest effort has been made so far on improving protection 
of the HTTP(S) protocol on top of Tor. Other protocols 
are not researched that well. There were several documented 
cases when application level leaked crucial user-identifying 
information [12|, [18|. Moreover, there is only limited number 
of applications which are studied well enough to be considered 
safe to use with Tor l20l . 

In this paper we show that using Bitcoin through Tor not 
only provides limited level of anonymity but also exposes the 
user to man-in-the middle attacks in which an attacker controls 
which Bitcoin blocks and transactions the users is aware of. 
Moreoever in colusion with a powerful miner double-spending 
becomes possible and a totally virtual Bitcoin reality may be 
created for such users. 

It turns out that by exploiting a Bitcoin built-in reputation 
based DoS protection an attacker is able to force specific 
Bitcoin peers to ban Tor Exit nodes of her choice. Combining 
it with some peculiarities of how Tor handles data streams a 
stealthy and low -resource attacker with just 1-3% of overall Tor 
Exit bandwidth capacity and 1000-1500 cheap lightweight Bit- 
coin peers (for example, a small Botnet) can force all Bitcoin 
Tor traffic to go either through her Exit nodes or through her 
peers. This opens numerous attack vectors. First it simplifies a 
traffic correlation attack since the attacker controls one end of 
the communication. Second, the attacker can can glue together 
different Bitcoin addresses (pseudonyms) of the same user. 
Third, it opens possibilities of double spending attacks for the 
mobile SPV clients, those which it was supposed to protect 
from such attacks. The estimated cost of the attack is below 
2500 USD per month. 

The rest of the paper is organized as follows. In section [IT] 
we provide information on Bitcoin and Tor internals required 



for understanding the attacks. In section III we describe how 
an attacker can get in the middle between Bitcoin clients and 
Bitcon network, effectively isolating the client from the rest 
of the Bitcoin P2P network. We also show that Bitcoin peers 
available as Tor hidden services may not solve the problem. 



In section IV we estimate connection delays experienced by 
the user and check for which malicious Exit bandwidth and 
number of malicious peers the attack becomes unnoticeable 
to the user. Section [VI] calculates the costs of the attack. In 
section 



VII we describe several possible countermeasures. 



II. Background 

In this section we provide details of the inner working of 
Tor and Bitcoin protocols. Many of these details do not appear 
in any specifications and were obtained by a careful analysis 
of the corresponding source code. This is especially true for 
Bitcoin for which there exists no official documentation except 
for the original white paper [14] and Bitcoin Wiki[3|. 



A. Bitcoin 

Bitcoin is a decentralized virtual currency and a payment 
system based on cryptography and a peer-to-peer network. 
Its main components are transactions and blocks. Blocks are 
created by Bitcoin miners by solving cryptographic puzzles 
of controlled hardness (called proofs of work). The proof of 
work consists of finding a cryptographic hash value for a 
block of transactions which starts with a certain number of 
leading zero bits (32 when Bitcoin was first proposed, 64 
zero bits at present). With each solved block a miner creates 
and earns 25 new Bitcoins. Hash of the previous block is 
included into the new block, which results in a chain of blocks 
or blockchain. The difficulty of the cryptographic puzzles is 
adjusted automatically by the network so that the network 
generates one block every 10 minutes on the average. Payers 
and payees of the system are identified by Bitcoin addresses 
which are base58-encoded hashes of their public keys. Money 
transfers from one Bitcoin address to another are done by 
creating a signed transaction and broadcasting it to the P2P 
network. Transactions are included into blocks by miners; once 
a transaction is buried under a sufficient number of blocks, it 
becomes computationally impractical to double spend coins in 
this transaction. 

Bitcoin is a peer-to-peer system where each peer is sup- 
posed to keep its copy of the blockchain, which plays a role of 
a public ledger. Whenever a block or a transaction is generated 
by a peer, it is broadcasted to other peers in the network. 
Upon receipt and verification of the block's proof of work the 
peer updates his copy of the blockchain. Bitcoind software 
does not explicitly divide its functionality between clients and 
servers, however Bitcoin peers can be grouped into those which 
can accept incoming connections (servers) and those which 
can't {clients), i.e. peers behind NAT or firewalls. Bitcoin 
users connecting to the Bitcoin network through Tor or VPN 
obviously also do not accept incoming connections. 

At the time of writing there are about 7,500 reachable 
Bitcoin servers and an estimated number of 100,000 clients. By 
default Bitcoin peers (both clients and servers) try to maintain 
8 outgoing connections to other peers in the network. If any 
of the 8 outgoing connections drop, a Bitcoin peer tries to 
replace them with the new connections. Using our terminology, 
a Bitcoin client can only establish a connection to a Bitcoin 
server. 



1 ) Bitcoin anti-DoS protection: As an anti-DoS protection, 
Bitcoin peers implement a reputation-based protocol with each 
node keeping a penalty score for every other Bitoin peer 
(identified by its IP address). Whenever a malformed message 
is sent to the node, the latter increases the penalty score of the 
sender and bans the "misbehaving" IP address for 24 hours 
when the penalty reaches the value of 100. 

2) Bitcoin peers as Tor hidden services: Tor hidden ser- 
vices (see section II-B3 1 are service-agnostic in the sense that 
any TCP-based service can be made available as a Tor hidden 
service. This is used by Bitcoin which recognizes three types 
of addresses: IPv4, IPv6, and OnionCat lfl5ll . Onioncat address 
format is a way to represent an onion address as an IPv6 
address: the first 6 bytes of an OnionCat address are fixed 
and set to FD87 : D87E : EB43 and the other 10 bytes are the 
hex version of the onion address (i.e. base32 decoded onion 
address after removing the ".onion" part). 

3) Bitcion peer discovery and bootstrapping: Bitcoin im- 
plements several mechanisms for peer discovery and bootstrap- 
ping. First, each Bitcoin peer keeps a database of IP addresses 
of peers previously seen in the network. This database survives 
between Bitcoin client restarts. This is done by dumping the 
database to the hard drive every 15 minutes and on exit. Bitcoin 
peers periodically broadcast their addresses in the network. In 
addition peers can request addresses from each other using 
GETADDR messages and unsolicitely advertise addresses using 
addr messages. 

If Tor is not used, when a Bitcoin clients starts, it first tries 
to populate its addresses database by resolving 6 hard-coded 
hostnamefn If Tor is used, Bitcoin does not explicitely ask Tor 
to resolvqj them but rather asks it to establish connections to 
these hostnames. 

If Tor is not used, the addresses for outgoing connections 
are taken from the addresses database only. In case Tor is used, 
every second connection is established to a DNS hostname. 
These DNS hostnames are called "oneshots" and once the 
client establishes a connection to such a hostname it requests 
a bunch of addresses form it and then disconnects and never 
tries to connect to it again. As a fallback if no addresses can 
be found at all, after 60 seconds of running the Bitcoin client 
uses a list of 600 hard-coded bitcoin addresses. 

Bitcoin nodes recognize three types of addresses: IPv4, 
IPv6, and OnionCat lfl5ll . For each type of addresses the 
peer maintains a state variable indicating if the bitcoin node 
is capable of using such address type. These state variables 
become important when using Tor: the only address type which 
is accepted from other peers is OnionCat type. Curiously, 
this results in that all IPv4 and IPv6 addresses obtained 
from oneshots are dropped and the client uses its original 
database. The opposite case also holds: if Tor is not used, 
onion addresses are not stored in the addresses database. 

4) Choosing outgoing connections: For each address in the 
addresses database, a Bitcoin peer maintains statistics which 

2 At time time of this writing one of these hostnames constantly failed to 
resolve into any IP address. 

3 When applications communicate with Tor they can either ask Tor to 
establish a connection to a hostname by sending a CONNECT command or 
to resolve a hostname by sending a RESOLVE command. 



among other things includes when the address was last seen 
in the network, if a connection to this address was ever 
established before, and timestamp of such connection. All 
addresses in the database are distributed between so called 
buckets. There are 256 buckets for "new" addresses (addresses 
to which the bitcoin client has never established a connection) 
and 64 for "tried" addresses (addresses to which there was at 
least to one successful connection). Each bucket can have at 
most 64 entries. When a peer establishes outgoing connections, 
it chooses an address from "tried" buckets with probability 
p = 0.9 — O.ln, where n is the number of already established 
ougoing connections. If an address is advertised frequently 
enough it can be put into up to 4 different "new" buckets. 
This obviously increases its chances to be selected by a user 
and to be transferred to a "tried" bucket. 

B. Tor 

Tor is the most popular low-latency anonymity network 
which at the time of this writing comprised of 5000-6000 
routers with an estimated number of daily users exceeding 
500,000 (not counting the botnet-infected nodes). Tor is based 
on ideas of onion routing and telescoping path-building design. 
When a user wants to connect to an Internet server while 
keeping his IP address in secret from the server he chooses the 
path consisting of three Tor relays (called Guard, Middle and 
Exit), builds a circuit and negotiates symmetric key with each 
one of them using the telescoping technique. Before sending a 
message to the server, the user encrypts it using the negotiated 
keys. While the message travels along the circuit, each relay 
strips off its layer of encryption. In this way the message 
arrives at the final destination in its original form and each 
party knows only the previous and the next hop. 

Tor tries hard to achieve low traffic latency to provide a 
good user experience, thus sacrificing some anonymity for 
performance. To keep latency low and network throughput 
high, Tor relays do not delay incoming messages and do not 
use padding. This makes Tor susceptible to traffic confirmation 
attacks: if an attacker is able to sniff both ends of the commu- 
nication, she is able to confirm that a user communicated with 
the server. If the first hop of a circuit is chosen at random then 
the probability that a malicious node will be chosen as the first 
hop (and thus will know the IP address of the user) converges 
to one with the number of circuits. Due to this, each user has 
a set of thre^f] Guard nodes. When a user builds a circuit the 
first hop is chosen from the set of trusted Guard nodes. 

The list of all Tor relays is assembled and distributed in the 
so called "consensus" document by nine trusted Tor authorities. 
For the purpose of traffic balancing the bandwidth of each relay 
is measured and reported. A user chooses relays for circuits 
proportional to their consensus bandwidth. Each relay in the 
Consensus is identified by his fingerprint (or ID) which is the 
SHA-1 hash of its public key. 

1) Tor stream timeout policy: Tor provides a SOCKS 
interface for application willing to connect to the Internet 
anonymously. Each connection to the SOCKS port by an 
application is called a stream. For each new stream Tor tries to 
attach it either to an existing circuit or to a newly built one. It 
then sends a begin cell down the circuit to the corresponding 

4 Will be reduced down to one Guard per user in the next Tor update 1 191 . 



Exit node asking it to establish a connection to the server 
requested by the application. In order to improve user's quality 
of service, if Tor does not receive a reply from the Exit node 
within 10 or 15 second^] it drops the circuit and tries another 
one. If none of the circuits worked for the stream during 2 
minutes, Tor gives up on it and sends a SOCKS general failure 
error message. 

2) Tor Exit policy: In order to access a Web resource 
anonymously through a Tor circuit, the Exit relay (the final 
relay in the circuit) should allow establishing connections 
outside the Tor network. This makes Exit relay operators open 
to numerous abuses. In order to make their life easier, Tor 
allows to specify an Exit Policy, a list of IP addresses and 
ports to which the Exit node is willing to establish connections 
and which destination are prohibited. When a client establishes 
a circuit, he chooses only those Exit nodes which allow 
connections to the corresponding destination. 

3) Tor Hidden Services: Tor is mostly known for its ability 
to provide anonymity for clients accessing Internet services. 
Tor Hidden Services are a less known feature of Tor which 
enables responder anonymity: a service can be contacted by 
clients without revealing its physical location. In order to 
achieve this a client and the hidden service choose at random 
and connect to a Tor relay (rendezvous point) and forward all 
the data through this rendezvous point. In more detail: 

1) The service generates a public key and chooses a 
small number of Tor relays at random which become 
his introduction points. 

2) It then generates a descriptor which contains the 
public key and the list of introduction points, and 

3) Publishes it at 6 different Tor relays having HSDir 
flagj^] These are called responsible HS directories. 
The choice of responsible HS directories is determin- 
istic and depends on the hash of the hidden service's 
public key and current day. 

4) Introduction points are instructed by the hidden ser- 
vice to forward connection requests from clients. The 
base32 encoding of the hash of the hidden service's 
public key (onion address) is then communicated 
to clients by conventional means (blog post, e-mail, 
etc.). 

When a client decides to connect to the hidden service, he: 

1) Determines the list of the responsible HS directories 
using the onion address and downloads the descriptor. 

2) Chooses a rendezvous point at random. 

3) Communicates the ID of the rendezvous point to 
the hidden service's introduction points which then 
forward it to the hidden service. 

When the hidden service receives the ID of the rendezvous 
point, it establishes a connection to it and the data transfer 
between the service and the client can start. All communica- 
tions between the client and the rendezvouz point, between the 
service and the rendezvous point and between the service and 

5 Tor waits for 10 seconds for the first two attempt and 15 seconds for the 
subsequent attempts. 

6 HSDir flag is assigned by Tor authorities to relays which wish to be a 
part of a distributing database and store descriptors of Tor hidden services. A 
relay should be up for at least 25 hours to get this flag. 



the introduction points are established over three -hop circuits. 
This hides the location of the hidden service and its clients 
both from each other and external observer. 

The hidden service or a client can determine the finger- 
prints of the responsible directories as follows. They first take 
all Tor relays which have HSDir flag in the consensus and 
sort their fingerprints in lexicographical order. Second, they 
compute the descriptor IDs of the hidden service which is the 
SHA-1 hash of a value composed of the following item^J 
public key of the hidden service, current day, and replica 
(which can be 0 or 1). The exact expression for the ID is 
of little importance here, the only important things are a) the 
ID changes every 24 hours, b) there are two replicas of the ID. 
Third they find the place in the sorted list of the fingerprints 
for the computed ID and take the next three relays' fingerprints 
(thus having 6 fingerprints it total since there are two replicas). 

III. Getting in the middle 

By combining subtle (however essential) details of Tor 
and Bitcoin protocols a low-resource attacker can force users 
which decide to connect to the Bitcoin network through Tor 
to connect exclusively through her Tor Exit nodes or to her 
Bitcoin peers, totally isolating the client from the rest of the 
Bitcoin P2P network. This means that combining Tor with 
Bitcoin may have serious security implications for the users: 

1) they are exposed to attacks in which an attacker controls 
which Bitcoin blocks and transactions the users is aware of; 

2) they do not get the expected level of anonymity. 

The main building blocks of the attack are: Bitcoin's 
reputation-based anti-Dos protection, Tor's stream manage- 
ment policy, the fact that connections between Bitcoin peers 
are not authenticated. Authors in [ 1 1 exploited the Bitcoin's 
reputation-based DoS protection to force all Bitcoin servers to 
ban all Tor Exit nodes. In this section we exploit the DoS 
protection, however we noticed that instead of just baning 
Bitcoin clients from using Tor the attacker might achieve much 
smarter results. The attack consists of four steps: 

• Inject a number of Bitcoin peers to the network. 
Note that though Bitcoin allows only one peer per 
IP address, it does not require high bandwidth. IP 
addresses can be obtained relatively cheap and on per- 
hour basis. 

• Periodically advertise the newly injected peers in the 
network so that they are included into the maximum 
possible number of buckets at the client side. 

• Inject some number of meduim-bandwidth Tor Exit 
relays. Even a small fraction of the Exit bandwidth 
would be enough for the attacker as will be shown 
later. 

• Make non-attacker's Bitcoin peers ban non-attacker's 
Tor Exit nodes. 

We now explain each step of the attack in more detail. See 
section 



IV for attack parameter estimation. 



1 A hidden service may also decide to use a secret key (aka descriptor- 
cookie), but for hidden services which are meant to be accessed by everybody 
it is not relevant. 



A. Injecting Bitcoin peers 

This step is rather straightforward. In order to comply with 
Bitcoin's limitation "one peer per IP address", the attacker 
should obtain a large number of IP addresses. It's not as hard 
as it might seem to be. The easiest way would be to rent IP 
addresses on per hour basis. The market value is 1 cents per 
hour per IP address. The important note is that the obtained 
IP addresses will not be involved in any abusive activity (like 
sending spam or DoS attacks) which makes this part of the 
attack undetectable. 

B. Advertising malicous peers 

The attacker is interested in that her Bitcon peers are 
chosen by Bitcoin clients as frequently as possible. In order to 
increase the chances for her peers to be included into "tried" 
bucket by factor 4, the attacker should advertise the addresses 
of her peers as frequently as possible. This mechanism would 
allow the attacker to inject less malicious peers. Note also 
that address advertisement is not logged by default and thus 
requires special monitoring to be noticed. 

C. Injecting Tor Exit nodes 

During this step the attacker runs a number of Exit Tor 
nodes. In order to get an Exit flag from Tor authorities, an 
attacker's Exit node should allow outgoing connection to any 
two ports out of ports 80, 443, or 6667. Such an open Exit 
policy might not be what a stealthy attacker wants. Fortunately 
for the attacker she can provide incorrect information about her 
exit policy in her descriptor and thus have an Exit flag while 
in reality providing access to port 8333 only. The attacker can 
do even better, and dynamically change the exit policy of her 
relays so that only connections to specific Bitcoin peers are 
allowed. We implemented this part of the attack: while the Tor 
consensus indicated that our relays allowed exiting on ports 80, 
443, and 8333 for any IP address, the real exit policy of our 
relays was accepting port 8333 for a couple of IP addresse^] 

D. Banning Tor Exit nodes 

In this phase, the attacker exploits the built-in Bitcoin anti- 
Dos protection. The attacker chooses a non-attacker's Bitcoin 
peer and a non-attacker's Tor Exit, builds a circuit through 
this Exit node and sends a malformed message to the chosen 
Bitcoin peer (e.g. a malformed coinbase transaction which is 
60 bytes in size and which causes the immediate ban for 24 
hours). As soon as the bitcoin peer receives such message it 
analyses the sender's IP address which obviously belongs to 
the Tor Exit node chosen by the attacker. The Bitcion peer 
then marks this IP address as misbehaving for 24 hours. If a 
legitimate client then tries to connect to the same Bitcoin peer 
over the banned Exit node, his connection will be rejected. The 
attacker repeats this step for each non-attackers's Bitcoin peers 
and each non-attacker's Tor Exit node. This results in that a 
legitimate Bitcoin user is only able to connect to Bitcoin over 
Tor if he chooses either one of the attacker's peers or establish 
a circuit through an attacker's Exit node. We validated this part 
of the attack by forcing about 7500 running Bitcoin peers to 
ban our Exit node. To do this we implemented a rudimentary 

8 We also allowed exiting to 38.229.70.2 and 38.229.72. 16 on any port which 
are IP addresses used by bandwidth scanners 



Bitcoin client which is capable of sending different custom- 
built Bitcoin messages. 

E. Defeating onion peers 

Bitcoin peers can be made reachable as Tor hidden services. 
Banning Tor Exit nodes will obviously not prevent Bitcoin 
clients from connecting to such peers. Nonetheless our obser- 
vations show that this case can also be defeated by the attacker. 

First the current design of Tor Hidden Services allows a 
low -resource attacker to DoS a hidden service of her choice J2J 
(this technique is called black-holing of hidden services). 
Before a client can contact a hidden service he needs to 
download the corresponding descriptor from one of the six 
responsible hidden service directories. These directories are 
chosen from the whole set of Tor relays in a deterministic way 



based on the onion address and current day (see section II-B3 1 



The attacker needs to inject six malicious relays that would 
become responsible directories. In other words she needs to 
find the right public keys with fingerprints which would be 
in-between the descriptor IDs of the hidden service and the 
fingerprint of the currently first responsible hidden service 
directory. Authors in 0 show that computationally it is easy 
to do. It can become a problem though for a large number of 
hidden services: for each hidden service the attacker needs to 
run at least 6 Tor relays for at least 25 hours, 2 relays per IP 
address. 

Fortunately for the attacker the fraction of Bitcoin peers 
available as Tor hidden services is quite small. During Au- 
gust 2014 we queried address databases of reachable Bitcoin 
peers [5] and among 1,153,586 unique addresses (port numbers 
were ignored), only 228 were OnionCat addresses and only 39 
of them were actually online (see Appendix A for the list of 
these Bitcoin onion addresses). This results in (1) a very small 
probability for a client to choose a peer available as a hidden 
service; (2) this makes black-holing of existing Bitcoin hidden 
services practical. 

Second, the attacker can at almost no cost inject a large 
number of Bitcoin peers available as Tor hidden services. It 
requires running only one bitcoind instance and binding it 
with as many onion addresses as needed. Thus users will more 
likely connect to attacker's controlled "onion" peers. 



Third, as was described in section II-A3 when running 
Bitcoin without Tor, onion addresses received from peers are 
silently dropped. Thus one can only obtain OnionCat addresses 
by either connecting to an IPv4- or IPv6-reachable peers 
through a proxj]^] or by specifying an onion address in the 
command line. 

IV. Estimating client's delays 

The steps described in the previous section imply that once 
a client decides to use Bitcoin network over Tor, he will only 
be able to do this by choosing either one of the attacker's 
Exit nodes or one of the attacker's Bitcoin peers. However 
for the attack to be practical a user should not experience 
significant increases in connection delays. Otherwise the user 
will just give up connecting and decide that Tor-Bitcoin bundle 

'Not necessarily Tor. 



is malfunctioning. In this section we estimate the number of 
Bitcoin peers and the amount of bandwidth of Tor Exit relays 
which the attacker needs to inject, so that the attack does not 
degrade the user's experience. 

Once the attacker completes the steps described in the 
previous section, for each user connecting to the Bitcoin 
network through Tor there are several possibilities (see Fig . [TJ . 

1) The user chooses one of the attacker's Bitcoin peers. 
The attacker does nothing in this case: the attacker 
automatically gains control over the information for- 
warded to the user. 

2) The user chooses one of the attackers Exit nodes. The 
attacker can use the fact that Bitcoin connections are 
not encrypted and not authenticated and redirect the 
client's request to Bitcoin peers under her control. 

3) The user chooses a non-attacker's Exit relay and a 
running non-attacker's Bitcoin peer. In this case, due 
to the ban the user's connections will be rejected. And 
the user will try to connect to a different Bitcoin peer. 

4) The user chooses a non-attacker's Exit relay and 
a non-attacker's Bitcoin peer which went offlin^^] 
In this case the Bitcoin client will wait until the 
connection times out which can be up to two minutes 
(see section II-B 1 1. This delay on the surface looks 
like taking prohibitively long time. However since 
during these two minutes Tor rebuilds new circuits 
every 10-15 seconds, trying new Exits at random, 
it actually makes the attacker's life much easier. It 
increases the chances that malicious Exit relay will 
be chosen. 
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Client 1 |^ Client 2 

Fig. 1. Client's state after the main steps of the attack 

A. Handling unreachable Bitcoin peers 

Before estimating the delays we consider case 4 in more 
detail. Our experiments show that for a Bitcoin client which 

10 Or never really existed: Bitcoin allows storing fake addresses in client 
addresses database. 



was already used several times prior to the connection over 
Tor, the addresses database contains 10,000 - 15,000 addresses 
and the fraction of unreachable Bitcoin peers among them 
is between 2/3 and 3/4. Abundance of unreachable addresses 
means that case 4 is the most frequent scenario for the client. 
Consider a client which chose an unreachable Bitcoin server 
and a non-attacker's Exit node. 

The Exit relay can send eitherp] 

1) An END cell with a "timeout" error code. In case 
of a "timeout" message, Tor sends a "TTL expired" 
SOCKS error message to the Bitcoin application 
which then tries another Bitcoin peer. 

2) An END cell with "resolve failed' error cod^] In 
case of "resolve" fail message, Tor drops the current 
circuit and tries to connect to the unreachable Bitcoin 
peer through a different Exit node. After 3 failed 
resolves, Tor gives up and sends a "Host unreachable" 
SOCKS error code, which also results in Bitcoin 
trying a different peer. 

The third and the most common option is that the exit relay 
will not send any cell at all during 10-15 seconds. As was 
described in the Background section that in case the Exit node 
does not send any reply within 10 or 15 seconds (depending 
on the number of failed tries) along the circuit attached to the 
stream, Tor drops the current circuit and attaches the stream to 
another circuit (or to a newly built one if no suitable circuits 
exist). In case Tor cannot establish connections during 125 
seconds, it gives up and notifies Bitcoin client by sending a 
"General failure" SOCKS error message. Bitcoin client then 
tries another peer. 

B. Estimating delays 

The facts that a) Tor tries several different circuits while 
trying to connect to unreachable peers and b) the fraction 
of unreachable peers in the client's database is very large, 
significantly increases the chances that a malicious Exit node 
is chosen. The attacker only need this to happen once, since 
afterwards all connections to the other Bitcoin peers will be 
established through this Tor circuit; Bitcoin client will work 
even with one connection. On the other side, unreachable 
nodes increase the delay before the user establishes its first 
connection. This delay depends on the number of attacker's 
Bitcoin peers and on how often the user chooses new circuits. 

In order to estimate the later, we carried out the following 
experiment. We were running a Bitcoin client over Tor and 
for each connection to an unreachable Bitcoin client we were 
measuring the duration of the attempt and the number of 
new circuits (and hence different Exit nodes). The cumulative 
distribution function of the amount of time a Bitcoin client 
spends trying to connect to an unreachable node is shown in 
Fig. [2] On the average a Bitcoin peer spends 39.6 seconds 
trying to connect to an unreachable peer and tries to establish a 
new circuit (and hence a different Exit node) every 8.6 seconds. 
This results in 4.6 circuits per unreachable peer. 



This is based on the Tor source code analysis and monitoring a running 
Tor instance. 

12 We observed this behaviour not only for hostnames but also for IP 
addresses. 
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Fig. 2. Time spent connecting to an unreachable node 



We now estimate how long it will take a user on average to 
establish his first connection to the Bitcoin network. This delay 
obviously depends on the number of the attacker's Bitcoin 
peers and the amount of bandwidth of her Tor Exit relays. We 
adopt a simple discrete time absorbing Markov chain model 
with only three states (see Fig [3]): 

• State 1: the Bitcoin client tries to connect to an 
unreachable peer; 

• State 2: the Bitcoin client tries to connect to a reach- 
able Bitcoin peer banned by the attacker; 

• State 3: Bitcoin peer tries to connect to an attacker's 
Bitcoin peer or chooses an attacker's Tor Exit node. 
State 3 is absorbing state, once it is reached, the user 
thinks that he connected to the Bitcoin network (while 
he is now controlled by the attacker). 
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3 

Fig. 3. Markov chain with probabilities for 400K of Exit capacity and 100 
malicious Bitcion peers. The client spends about 0.5 seconds in State 2 and 
about 40 seconds in State 1 

After composing the fundamental matrix for our Markov chain, 
we find the average number of steps in two non-absorbing 
states. Taking into account the average amount of time spent 
by the user in each of the states (we use our experimental data 
here), we find the average time before the absorbing state. We 
compute this time for different number of Bitcoin peers and 
Tor Exit relay bandwidth controlled by the attacker. The results 
are presented in Fig |4] We have taken a concervative estimate 
that the fraction of unreachable Bitcoin peers in the client's 
database is 2/3 = 66%, also the client spends only about 0.5 
seconds in State 2 and about 40 seconds in State 1. 

Fig [4] shows that an attacker having 100,000 of consensus Exit 
bandwidth and 1000 Bitcoin peers is able to carry out the attack 
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A. Possibility of double spending and "virtual reality" 

The attacker can defer transactions and blocks. In case of 
blocks we can send dead forks. In collusion with a powerful 
mining pool (for example 10-20% of total Bitcoin mining 
capacity) the attacker can create fake blocks. This enables 
double spend, however to make this relevant the amount should 
exceed what such miner would be able to mine in the real 
Bitcoin network. Also complete alternative Bitcoin reality for 
all the users who access Bitcoin solely through Tor is possible. 
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Fig. 4. Average time before the first connection 



while keeping the average delay below 5 minutes. For example 
attacker controlling a small botnet can afford that many peers 
(she will need 1000 peers with public IPs or supporting UPnP 
protocol). An attacker having consensus weight of 400,000 and 
very few peers can decrease the average delay to about two 
minutes. Such a bandwidth is achievable by an economy level 
attacker as will be shown in section [VI] 

The line corresponding to 4000 attacker's Bitcoin peers in 
Fig. [4] is not as unrealistic as it may seem. Recall (see section 
|1I-A4| > that each Bitcoin peer address can go to up to 4 "new" 
buckets at the client's side. This can be used by a persistent 
attacker to increase the choice probability for her peers by a 
factor 4 (in the best case) which means an attacker can have 
significantly less than 4000 peers. 



C. Clients with empty addresses cache 



VI. Attack Costs 



A. Tor Exit nodes 



As was pointed in section |II-A3| all IPv4 and IPv6 ad- 
dresses received from DNS-oneshots are dropped by a Bitcoin 
client if Tor is used. If the addresses database of a client is 
empty and all the seed nodes are banned, the client can connect 
to hidden services only. This is a limitation of our approach. 

V. Opportunistic deanonymisation and traffic 

CORRELATION 

For a traffic confirmation attack an attacker needs to 
control both end of a users 's communication and the fact 
that the attacker now controls one end of the communication 
significantly increases the success rate of the attack. The 
attacker sends a traffic signature down the circuit in in hope 
that some users chose the attacker's Guard nodes. Even if it is 
not the case, the attacker can try to reveal the Guard nodes of 
users by dropping their circuits and forcing them to reconnect 
(thus choose another circuit which would contain one of the 
attacker's middle nodes). 

Attacker would be also in position to perform time corre- 
lation attacks in case the user is accessing Tor Hidden services 
and making payments with Bitcoin over Tor on them. For 
this it would be sufficient for the attacker to get control of 
the HSDir servers responsible for the onion addresses of the 
relevant hidden service. 



During July 2014 we were running a non-Exit Tor relay 
for 30 USD per month. We set the bandwidth limit of the 
relay to 5 MB/s which resulted in traffic of less than 15GB 
per hour. The consensus bandwidth of this relay fluctuated 
between 5,000 and 10,000 units^] While the total weighted 
consensus bandwidth of all exit nodes was about 7 million 
units, the weighted consensus bandwidth of relays allowing 
exiting at port 8333 was about 5.7 million units. Assuming 
that we could achieve the same consensus bandwidth for an 
Exit node this gives the probability of 0.08%-0. 17% for our 
relay to be chosen for Exit position by a user. Given that 10 TB 
of traffic is included into the server's price and one has to pay 
2 EUR per additional 1 TB, it would cost an attacker 360 USD 
to have 180 TB of traffic per month. The corresponding speed 
is 69 MB/s (69,000 consensus bandwidth units). By running 6 
such relays the attacker can achieve 400K of bandwidth weight 
in total for the price below 2500 USD (2160 USD for the traffic 
and 240 for renting fast servers). 

Thus having a consensus weight close to 400,000 is possi- 
ble for an economy-level attacker. The attacker can also decide 
to play unfair and mount a bandwidth cheating attack which 
would allow her to have a high consensus weight while keeping 
the budget of the attack even lower. This is especially possible 
since Bitcoin traffic by itself is rather lightweight and high 
bandwidth would be needed only in order to drive Tor path 
selection algorithm towards attacker's nodes. 



B. Bitcoin peers 



The attack described in section III suggests the attacker 
injects a number Bitcoin peers; at the same time Bitcoin 
network allows only one peer per IP address. Thus the attacker 
is interested in getting as many IP addresses as possible. 
Currently there are several options. The cheapest option would 
be to rent IP addresses on hourly basis. The market price for 
an IP address is 1 cent per hour ifTTl . This results in 7200 
USD per 1000 IP's per month. 

From these computations it is clear that attacker would 
do better by investing in Exit bandwidth rather than running 
Bitcoin peers (unless she controls a small botnet), and the only 
limitation for her would be not to become too noticeable. An 
attacker that has 400K (7% for port 8333) of Tor Exit capacity 
would cost about 2500 USD. 

13 A unit roughly corresponds to 1 KB/s of traffic 



VII. COUNTERMEASURES 

Our attack is very effective due to a feature of Bitcoin 
which allows an easy ban of Tor Exit nodes from arbitrary 
Bitcoin peers. One possible countermeasure could be to relax 
the reputation-based DoS protection. For example each Bitcoin 
peer could have a random variable, which would decide 
whether to turn ON or OFF the DoS protection mechanism 
with probability 1/2. As a result the attacker might be able to 
DoS at most half of the network, but on the other hand he will 
not be able to ban any relays or VPNs from ALL the Bitcoin 
peers. 

An obvious countermeasure would be encrypt and authen- 
ticate Bitcoin traffic. This would prevent even opportunistic 
man-in-the-middle attacks (i.e. even if the user is unlucky to 
choose the malicious Exit relay). 

Yet another possible countermeasure is to run a set of "Tor- 
aware" Bitcoin peers which would regularly download Tor 
consensus and make sure that Bitcoin DoS countermeasures 
are not applied to servers from the Tor consensus. Such relays 
however would be vulnerable to DoS via Tor attack. 

Finally, Bitcoin developers can maintain and distribute a 
safe and stable list of onion addresses. Users which would 
like to stay anonymous should choose at least one address 
from this list. There currently exists a short and not up-to-date 
list of Bitcoin fallback onion addresses j8). 
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Appendix 

A. List of Reachable Bitcoin Onions 

In this Appendix we list 39 Bitcoin onion addresses which 
we found to be reachable on the 5th of August 2014. In 
order to get this list we queried reachable for the time of the 
experiments Bitcoin peers by sending four GETADDR messages 
to each peer. A Bitcoin peer can reply to such message by 
sending back 23% of its addresses database but not more than 
2500 addresses. A peer can store 16,384 addresses at most 
which means that sending 4 GETADDR messages is not enough 
to extract the complete peer's database. However we expect 
that there is a big overlap between the databases of different 
peers. Some of the discovered reachable onion addresses begin 
or end with meaningful text like: BTCNET, BITCOIN and 
belong to Bitcoin developers, pools or services. 
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